A continuing trend within the networking industry is a move to enhance IEEE 802.3/Ethernet performance, using switched and/or full duplex Ethernet capability. This is seen as yet another "mid life kicker" to Ethernet, either preserving existing workstation controllers and providing "dedicated Ethernet" (full 10 Mb/s) to each desktop, or by upgrading the existing adapter to full duplex, for higher performance and enhanced support for interactive applications.
For the current generation of Ethernet controller products, there are two fundamental areas that require modification to support the full duplex capability. Basically these are:
(i) The capability to transmit and receive simultaneously (without collision);
(ii) The capability to "auto-negotiate" between the hub and the end station to determine if the full duplex capability is supported.
The intent of full duplex operation is clear--to increase the performance of an Ethernet link by taking advantage of the 10BASE-T topology, which provides a full duplex communications link (separate transmit and receive circuits and cabling), but is normally used in a half duplex mode for compatibility with existing coax based Ethernet.
There are two components to this performance increase. The first is the physical capability to actually be able to simultaneously transmit and receive. The second is the effective elimination of collisions. Since it is assumed that contention will not occur (an active receiver is no longer an indication that the transmit MAC process must defer), then the end station effectively assumes it can always transmit. This second characteristic has more impact at the hub/repeater than at the end station.
At the hub end, this means that a repeater is inadequate (since it can only deal with a single active receive port at any one time). The repeater must be replaced with a bridge function, which provides the required level of "store and forward" buffering, and routes the packet according to its source/destination address characteristics. This may be by means of the MAC address (in which case it is technically a bridge), or an internetwork address (in which case it would be classed as a router). The integration of this bridge/router functionality into a high performance multiport unit is effectively what the industry refers to as a "switch" in Ethernet terms. Hence from an external perspective, a node (end station) would not be able to detect the difference between being connected to a bridge or a switch.
The examination of a "Switched Ethernet" hub function is not the focus of the present invention, although it is assumed that to implement such a system, a switched hub which would be able to detect (and hence take action upon) an end stations' ability to support a full duplex mode, would be highly desirable. The remainder of this specification will focus on the impact to the end station operation. Note however that typically bridges and routers (hence switches) employ standard Ethernet controller silicon to perform the hub (switch) port function, so this scheme is in fact applicable to both end stations and switch ports.
Consider a typical integrated Ethernet controller such as the PCnet-ISA or MACE controllers manufactured by Advanced Micro Devices (AMD). The following functions would be desired in a full duplex capable version of such a controller product:
(i) Power up in the half duplex (standard Ethernet) mode of operation.
(ii) Determine if the 10BASE-T port receiver is active (if not, assume use of the AUI and remain in half duplex mode). Note that this function is applicable to controllers which support more than one physical medium interface (eg. AUI and 10BASE-T), such as the AMD Pcnet-ISA (Am79C960) and MACE (Am79C940) as in the example of FIG. 1b.
(iii) If the 10BASE-T port is active, determine if the hub/link can support full duplex (and set an internal bit to indicate the link is "full duplex capable").
(iv) If so, switch to the full duplex mode (or move to full duplex if forced by a user programmable bit).
(v) Continue to mimic PCnet-ISA/MACE functionality from a software perspective (loopback, transmit/receive, interface/buffering etc.)
(vi) Allow either the switch port or the controller to request that the link be degraded to standard half duplex 10BASE-T mode, with minimal impact.
Items (iv) and (v) are discussed briefly in the Simultaneous Transmit/Receive section, and items (i) through (iii) and (vi) are discussed in the "Auto-Negotiation" Capability section.
Simultaneous Transmit/Receive
Many Ethernet controller products (including the AMD PCnet family and the MACE product) can architecturally support full duplex operation at the bus interface level.
However, since standard Ethernet (half duplex) operation was always assumed at the network interface, typically some implementation trade offs have been made in many controllers, which would need to be addressed in order to support full duplex. These would include (but may not be limited to):
(i) Two CRC generator/checker circuits must be present to support CRC generation at the transmitter, and checking at the receiver, both being operable simultaneously.
(ii) When in the full duplex mode, the transmit deferral process, the pseudo random number generator for the backoff algorithm, the deferral/retry process and the slot time counter are not required. However, the IPG timer will be necessary, so back-to-back packets will have a minimum of 9.6 ms interpacket gap IPG enforced (for reasons of interoperability with existing LAN analyzer equipment, and existing software interrupt latency issues).
(iii) On transmission, a Loss of Carrier (LCAR) indication will be reported since the transmit to receive loopback function will be disabled in the transceiver, and hence the controller will not be able to detect its own transmission (a normal Ethernet requirement). Either the software driver routine could ignore this fact when in the full duplex mode, or preferably the controller would create a "dummy Carrier" to mask this from the driver.
(iv) The normal blinding period after a transmission, during which the SQE Test sequence from the MAU appears, would be disabled, since an incoming frame may be lost if it commences immediately after a transmission attempt.
(v) The Collision Error (CERR) or SQE Test Error detection and reporting would also be disabled. Since the MAU will have the collision circuit disabled (allowing transmit and receive activity to continue without generation of collision, as opposed to the standard 10BASE-T case), no SQE Test sequence will occur after the end of a transmission. This could be masked in the driver, but it would preferably be handled by the controller itself.
It is assumed that for a full duplex capable controller, the default operation of the device will be to attempt to establish a full duplex link if the 10BASE-T receiver is detected as active. The programming capabilities of the controller are considered in more detail under the "Controller Programming" section.
"Auto-Negotiation" Capability
The objective of the "Auto-Negotiation" function of the present invention is for either end of the link (both end station and hub/switch port) to ascertain the capabilities supported by the device at the other end. Auto-Negotiation is performed out of band (using the normal 10BASE-T link test pulse function), so adds no packet or protocol overhead to the network.
There are schemes which have been utilized to provide full duplex capability in a communications network such as that disclosed in U.S. Pat. No. 5,121,382, entitled STATION TO STATION FULL DUPLEX COMMUNICATIONS IN A COMMUNICATIONS NETWORK. This alternative mechanism for negotiating the capability of the devices at either end of a link uses an "in-band" signaling scheme. An in-band scheme implies that the normal communications channel is utilized as the signalling mechanism. Such a scheme could be envisaged in which one device initiates a special Ethernet frame, advertising that it has enhanced capabilities. The device at the other end of the twisted pair link (referred to subsequently as the "link partner") would receive this, interpret it, and respond appropriately if it had similar capabilities. Hence a relatively simple packet based scheme could be devised to negotiate the full duplex capability.
Although at first this system appears simple and to incur minimal overhead (since the existing signalling is utilized), the scheme has some problems associated with it which are enumerated below:
1. Normal Ethernet MACs do not generate (or intercept) packets themselves, they merely convert packets queued in memory (by the host) for transmission and transmit them over the Ethernet, or receive messages from the Ethernet and place these in memory for processing by the host. Hence a packet based scheme that would be automatic would involve the host in queuing an appropriate message to request the full duplex capability, or awaiting such a request from another device. This would either be the responsibility of the host software, or would have to be accomplished using additional hardware. A software based approach may be preferable from a flexibility point of view, since the specific frame contents and the timing of the request/acknowledge can be tuned for different network protocols. However, this burdens the host processor, and may be a significant issue in a bridge device which already has significant processing overhead. A hardware approach may avoid host processor interaction, but may be inflexible if the messaging scheme requires any adaption for compatibility with the many dissimilar network operating systems that are popularly deployed.
2. Since there is no immediate way of knowing whether the other link partner device supports the full duplex capability, the special negotiation frame may have to be sent a number of times if no response is received. It may also require the negotiation frame to be continuously sent on a periodic basis. Both of these issues mean that finite amount of bandwidth is used by the scheme.
3. Since a special type of negotiation frame must be sent, it would be preferable that only the link partner should receive the frame. However at power up, it is difficult to recognize the station ID of the link partner. This is especially true for the end station learning the address of the switch (bridge) port, since generally the bridge will be transparent (it will leave the source address (SA) field in the packet as the originating station, and not the address of the bridge port that delivered the packet to the end station). Hence it may require use of a multicasting scheme. This in itself has two fundamental issues associated with it.
Firstly, the widespread use of multicast packets should be avoided. Since address detection of multicast addresses is imperfect (it is based on a mathematical "hashing" algorithm ), stations will receive some multicast frames which pass the hash table, but are still not intended for the station. In this case, further software processing is required to eliminate all multicast messages other than those specifically intended to be received. All of this takes additional software resources, and adds to the processing burden of the bridge, which already typically has other multicasts addresses/filtering to do for normal network traffic.
Secondly, the allocation of multicast addresses requires administration, in that other devices on the network may either use the multicast address specified for the negotiation frame, or may use a multicast address which hashes to a similar value. This is especially true when multiple network operating systems and/or protocols are considered. Hence the potential for additional overhead exists, since any existing multicast frames on the network (used by the network operating system and/or network protocol) and the negotiation frames may both be received by any network station which can accept either.
4. The negotiation frame may be construed as some other type of "normal" data packet in some network protocols, in which case it would be passed to the normal network application, even through the contents of the frame are essentially illegal or meaningless from the perspective of the application.
5. The use of special "test packets" which are shorter than the minimum specified for an 802.3 fragment (96 bit times) or frame (512 bit times following preamble and SFD) should be avoided, since these may cause other physical layer network statistics to be falsely corrupted (such counters may exist in managed repeaters for instance). In addition, some network controllers may be designed not to receive illegally shod frames (such as "test packets"), in order to minimize passing of errors resulting from normal collision fragments to the host system.
Accordingly what is needed is a method and apparatus for allowing for the ability to utilize the enhanced capabilities of controllers when utilized in existing networks without the above identified disadvantages. The method and apparatus should be capable of interfacing to controllers with lower level capabilities as well as those with enhanced capabilities. The system should also be one that is minimally disruptive to the network. The present invention provides such a method and apparatus.